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(1) Real parly in interest 

The real party in interest is 'Virtual agility, Inc., a Delaware corporation having a place of 
business at 17Lakeview Rd., Winchester, MA 0.1890. 

25 

(2) Related appeals and interferences 

The present patent application is the parent of a OP. USSN 10/765,424, Douglas F. 
Beaven, et al., System for performing collaborative tasks, filed 1/27/04. An appeal is 
pending in 10/765,424. An Appeal Brief \ms fi led 9/1 7/2007. 

30 

(3) Status of claims 

Claims 191-211 are pending in the application; claims 1-190 have been canceled in the 
course of prosecution. Claims 191-211 all stand rejected. There are two independent 
35 claims, 198 and 211. Claims 191-197 are dependent from claim 21 1 and claims 199-210 
are dependent from claim 198. Claims 191-194 and 197-21 1 all stand rejected under 35 
U.S.C, 102(e) as being anticipated by Buteau, et al.., U.S. 6,442,557, henceforth 
"Buteau". Claims 195 and 196 stand rejected under 35 U.S.C. 103(a) as obvious over 
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the combination of Buteatt and Official Notice that systems for sending messages and 
systems for maintaining discussions are well known For the convenience of the Board, 
the foi lowing Appeal bases reference;} to the Specification and Figures of USSN 
09/312,740 on U.S. Published Patent Application 2004/0186762, which is a CIP of USSN 
5 09/312,740 and contains the complete Detailed Description and Drawing of USSN 
09/3 12,740. The material from USSN 09/312,740 in 2004/0 1 86762 begins at paragraph 
0049 and ends at paragraph 01 S3 and includes HGs. 1-39. 

(4) Status of amendments 

10 The claims stand as amended on 21 February 2007. No further amendments have been 
made. 

(5) Summary of claimed subject matter 

Background 

15 Applicant's invention is a technique for supporting management of a collaborative 
activity. The technique is implemented in a computer system which includes a database 
that, contains a representation of a. model of the collaborative entity and a. graphical user 
interface which permits non-technical users to view and manipulate the model and access 
information via entities belonging to the model. 

20 

Software which supports management of a collaborative activity is of course well .known. 
Broadly speaking such software fails into two classes: 

• Software which is usable by non-technical people but. provides the user with only a 

single simple model for the collaboration and 
25 • Software whidi permits the user, to make am kind of mode! w hates et tW the 

collaboration but is not usable b\ non-technical people 
The pi obi em vuth the fust class of software is ih*, mflexsbiiits of the model The 
problems with the second class are the eomplevih. of the ss stems and the dtiiicuines of 
making models from scutch 

30 

Applicant's solution 

Applicant's solution to the problems of the prior art is a modeling technique which is 
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simple enough for non-technical collaborators to understand and use but powerful enough 
to model many different kinds of collaborations. The components of the solution are: 

• a model which has at least two kinds of hierarchies and permits a given model entity 
to belong to more than one kind of hierarchy. The hierarchies provide different 

5 contexts through which collaborators may view and access model entitles, 

• a graphical user interface for manipulating the hierarchies and the model entities 
which requires no technical training to use. 

In a preferred embodiment, the model entities are goals and projects on the one hand and 
10 domains on the other. One of the kinds of hierarchies is a goal and projects hierarchy of 
things to be done and projects for doing them; another kind is a domain hierarchy of 
functional areas of the collaboration. A goal or project of the model may belong 
simultaneously to a domain hierarchy and a goal and projects hierarchy and may be 
viewed or accessed via either hierarchy. Domains are explained at 0057 of 
IS 2004/0186762 and goals at 0059. A screen of the GUI that displays a hierarchy of goals 
and projects is shown in FIG 3; a screen of the GUI which displays a hierarchy of 
domains is shown in FIG. 8; a screen of the GUI which displays goals belonging to a 
domain is shown in FIG 9; a screen which shows goals and projects as they appear in the 
domain hierarchy is shown in FIG. 16. The GUI may be used to control access to goals 
20 and projects, to create, modify,, and/or delete goals and projects, to assign a goal or 
project to a location in a domain hierarchy or a goal and project hierarchy, to access 
information via a goal or project, and to view goals or projects ordered by a value in the 
goal or project's information. 

25 Independent claim 198 addresses the feature of the above system that a model entity may 
be created and assigned to a first and a second hierarchy; independent claim 211 
addresses that feature as well as other operations; both claims set forth the limitation that, 
the system's GUI may be used by persons who are not specialists in information 
technology. In the following, the limitations of these claims will be mapped to the 

30 Specification and Drawing. The mapping is for the convenience of the Board and is not 
intended to limit the scope of the claims. 
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Claim 211 



1 211, A system for supporting management of a collaborative activity by 

2 persons involved therein (pars. 0080-0105), the persons not being 

3 specialists in information technology {pars. 01 30-0 1 3 1 > and 

4 the system comprising: 

5 a representation (par. 0079) of a mode! of the collaborative 

6 activity, the representation being accessible to a processor and the model 

7 of the collaborative activity including mode! entities ('domains, FIG. 6, 

8 par 0123, and goals., FIG. 3.. par. 0127). the model entities providing 

9 access to information concerning the collaborative activity (FiGs. 16-21.. 
SO par. 0131), being organized into a plurality of hierarchies (domain and 
1.1 goal hierarchies. FIG. 6 and FIG 3) having a plurality of types, and a given 
12 model entity being capable of simultaneously belonging to a hierarchy 
33 having one of the types and a hierarchy having another of the types {goals 

14 sorted by domain hierarchy, FIG. 16. par. 0132); and 

15 a graphical user interface tor the system {par. 0085, pars. 0140- 

16 0181) which the processor provides to the persons, the graphical user 

17 interface permitting a person of the persons to perform operations on a 

18 model entity as limited by a type of access which the person has to the 
59 model entity (FIG. 27, par 0165).. the operations including controlling 

20 access to the model entity (FIG 27, par. 0165), creating (par, 0125)., 

21 modifying (par. 0161), and/or deleting (par. 0163) the model entity, 

22 assigning the model entity to a location in a hierarchy (FIG 13 and par. 

23 0144), accessing and/or modifying the information concerning the 

24 collaborative activity via the model entity {FIG. 33 and par. 0172), 

25 viewing .model entities as ordered by a hierarchy to which the entities 

26 belong (FIG. 16, par. 0132), and viewing model entities as ordered by a 

27 value in the information concerning the collaborative activity to which the 

28 entities give access (FiGs. 1 8 and 20, par. 01 79). 

Claim 198 

1 198, A method of supporting management, of a collaborative activity in a 

2 system which includes a processor, the processor having access to a 

3 database containing a model of the collaborative activity (pars. 80-105), 

4 the model including representations of model entities (domains, FIG. 6, 

5 par. 0123, and goals, FIG. 3, par. 0127). a given representation of a model 

6 entity being capable of simultaneously belonging to hierarchies including 

7 a hierarchy and another hierarchy (goals sorted by domain hierarchy, FIG. 
S 16, par. 0132), and the representations of model entities providing access 

9 to information relating to the collaborative activity (FIGs. 16-21, par. 

10 0131), the processor providing an interface {par. 0085, pars, 0140-0181) 
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! 1 for one or more users of the system who are not specialists in information 

12 technology (pars. 0130-0131), and the method comprising the steps 

13 performed in the system of: 

14 receiving a definition of a mode! entity belonging to the model of 
55 the collaborative activity' from a user via the interface (par. 0125) and 

16 responding thereto by producing a representation of the model entity in the 

17 database; and 

18 receiving a first indication of a first hierarchical relationship 

19 between the model entity and another model entity belonging to the 

20 hierarchy from the user via the interface and responding thereto by relating 

21 the model entity to the other model entity in the hierarchy (goal hierarchy, 

22 FIG. 13, par. 0144) and 

23 receiving a second indication of a second hierarchical relationship 

24 between the model entity and a third model entity belonging to the other 

25 hierarchy from the user via the interface and responding thereto by relating 

26 the model entity to the third model entity in the other hierarchy (domain 

27 hierarchy; FIG. 7, par. 01 23). 



30 (6) Grounds of rejection to be reviewed on appeal 

The grounds of rejection to be reviewed on appeal are the following: 

• the rejection of claims 211 and claims 191-194 and 197 under 35 U.S.C. 102(e) as 
anticipated by Buteau, et ai., U.S. 6,442,557, henceforth "Buteau" 

* the rejection of claims 195 and 196 under 35 U.S.C. 103 as obvious over the 
35 combination of Buteau and Official Notice that systems for sending messages and 

systems for maintaining discussions are well known, and 

♦ The rejection of claims 198-210 under 35 U.S.C. 102(e) as anticipated by Buteau. 
The rejection of claims 211, 191-194, and 197 is being argued separately from that of 
claims 198-210; the rejection of claims 95 and 96 stands and falls with the rejection of 

40 claims 21 1, 191 -1 94, and 197. 

(7) Argument 

As set forth in MPEP 2131, a rejection of a claim under 35 U.S.C. 102 requires that the 
reference which forms the basis of the rejection disclose all of the limitations of the 
45 rejected claim. In the following, it will be demonstrated that Buteau fails to disclose 
many of the limitations of claims 211 and 198, that the rejections of these claims under 
35 U.S.C. 102 as anticipated by Buteau cannot stand, and that because claim 211 as 
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anticipated by Buteau cannot stand, the rejections of claims 195 and 196 under 35 U.S.C. 
103 also cannot stand. 

The Buteau reference 

5 As set forth in the Abstract, the Buteau reference discloses a system that evaluates an 
enterprise architecture to see how architectural changes to the enterprise affect the 
enterprise architecture. The enterprise architecture is described in terms of the 
Department of Defense's Technical Architecture Model for Information Management 
(TAFIM). Buteau's FIG. 2 shows the TAFIM model. In Buteau's system, the TAFIM 

10 model is represented using tables in a relational database system. The tables define three 
subdivisions of the TAFIM model; a work flow model, an information model, and a 
technology model. An enterprise architect specifies a particular enterprise architecture 
belonging to the TAFIM model by placing information in the data structures of the 
model's representation in the relational database system (col. 2, lines 21, 22, col. 6, lines 

15 44-48). The Buteau reference thus discloses a system that employs a single kind of 
model. The model may further be manipulated only by a technically trained person. 

The implementation of the model in the relational database system is shown in FIGs. 4-7. 
The figures use entity -relationship diagrams to define the relationships between the tables 

20 making up the model. In entity -relationship diagrams, tables in which entries may have 
hierarchical relationships to each other are indicated by arrows which loop back into the 
table. As shown in FIG. 7, four of the tables in Buteau permit hierarchical relationships 
among the table's entries: Organization table 290, discussed at col. 9, line 59-eol. 10, line 
20, Info Type table 540, discussed at col. 15, lines 42-67, Info Repository table 520, 

25 discussed at col. 16, lines 26-5 L and Info Format Table 570, discussed at col. 17, lines 
21-38. It is clear from the nature of these tables that an entry in one of the tables cannot 
be a member of a hierarchy in another of the tables; the discussions of the tables further 
make it clear that an entry in one of the tables cannot be a member of two different 
hierarchies in the table (the entry can of course be both a member of a hierarchy and a 

30 member of a subhierarchy of that hierarchy). 
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Buteau's user interface is described at col. 22, lines 20-62, It has a simple interface, 
shown in FIG. 8, for inputting information to the database, but all other operations 
require the user to write sophisticated SQL code. See in this regard lines col. 22, lines 56- 
58. FIG. 9 shows the screen in which the SQL code is written and FIG. 10 shows the 
5 screen on which the output of the query of FIG. 9 appears. 

Continuing in more detail with the GUI of FIG . 8, there is no real disclosure in Buteau of 
what the GUI is intended to do. The GUI is an edit GUI; what is being edited is 
information relevant to the Center for Applied Technology organization, which is a part 

10 of the Defense Systems organization. The user can select a location belonging to the 
Center for Applied Technology from the drop down menus listed under "Location" and 
then having selected the location, may apparently change a "Quantity" value for the 
location and write a comment having to do with the quantity value. The lists in the drop 
down menus are attributes that are determined by the "enterprise architect" (col. 22, lines 

15 21-22). 

Important differences between Buteau and Applicant's claims 221 and 198 include the 
following: 

• the enterprise architectures represented by Buteau's system are relatively static; they 
20 are designed for use by architect's and planners (col. 6, line 15} and changes in a 

particular enterprise architecture are made by an enterprise architect (eoL 22, lines 22- 
23). Non-technical users can view information from the model and edit the 
information in the model but cannot change the model itself. 

• There is only limited visibility of Buteau's model in Buteau's GUI; there is nothing in 
25 Buteau's GUI corresponding to any of Applicant's FIGs. 3, 6, 7-10, 12-24, 26-33, 

34A-39. The GUI for non-technical users consists of the data input screen shown in 
FIG. 8 and described at col. 22, lines 20-32. Technical users interact with the system 
by writing SQL queries, as shown in FIGs. 9 and 10 and described at col 22, lines 
31-62 
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• Any operation in Bureau's system beyond those possible using the GUI of FIG. 8 

require writing SQL queries. The need to do this makes these operations too difficult 
for non -technical users. 

• Buteau's model does not permit an entity in the model to be a member of two 
5 different types of hierarchies; consequently, Buteau's model does not permit the use 

of different types of hierarchies to see and access the information in the mode! from 
differen t per specti ves . 

• There is no disclosure in Buteau indicating that non-technical users of Buteau's 
system can change the form of Buteau's model and consequently there is no 

10 disclosure that users of Buteau's system can "assignf] the model entity to a location in 
a hierarchy", or "view[j model entities as ordered by a hierarchy to which the entities 
belong". Non-technical users, finally, cannot "viewfl mode! entities as ordered by a 
value in the information concerning the collaborative activity to which the entities 
give access". 

.15 

Patentability of claim 211 over Buteau 

Claim 21 1 includes the following limitations which are not disclosed in Buteau: 
» Because non-technical users of Buteau's system can employ Buteau's interface only 
to edit data regarding entities in the model Buteau is not "a system for supporting 
20 management of a collaborative activity by persons involved therein, the persons not 

being specialists in information technology" (claim 21 1, lines 1-3). 

• While Buteau's model includes hierarchies, it does not permit a model entity to 
belong to two different types of hierarchies (lines 10-14), 

• Buteau's graphical user interface permits "persons [who are not] specialists in 
25 information technology" only to edit data regarding entities using screens like those 

shown in FIG. 8. As would be expected from this, there is no disclosure in Buteau 
which indicates that a non-technical user can employ Buteau's GUI to perform any of 
the claimed operations of 

- "controlling access to the model entity"; 
30 - "assigning the model entity to a location in a hierarchy" or 
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- "viewing model entities as ordered by a value in the information 
concerning the collaborative activity to which the entities give access" 

Because none of the foregoing limitations of Applicant's claim 211 are disclosed in 
5 Buteau, Examiner's rejection of the claim under 35 U.S.C. 102 as anticipated by Buteau 
is without foundation. Further, because Buteau fails to disclose all of the limitations of 
independent claim 211, it similarly fails; to disclose all of the limitations of the claims 
dependent from claim 211. As will be explained in detail below, some of these 
dependent claims contain further limitations that are not disclosed in Buteau and are 
10 consequently patentable in their own rights over the reference. 

Patentable weight of "persons not being socialists in information technology" 

fit her Office action of 11/21/2006 and her final Office action of 5/21/2007, Examiner 

argued that the language "the persons not being specialists in information technology" 

15 had no patentable weight. While the patentability of claim 211 over Buteau does not 

depend on whether the language "the persons not being specialists in information 

technology" has patentable weight, it is worth pointing out here that MPEP 2 1 00-42, Rev, 

5, Aug. 2006, f. Preamble Statements Limiting Structure requires a contrary conclusion. 

The cited location in the MPEP reads as follows: 

20 Any terminology in the preamble that limits the structure of the claimed 

invention must be treated as a claim limitation. 

hi claim 211, the "graphical user interface" is a structural component of the claimed 
invention, and it is this structural component that is limited by the "users who are not 
25 specialists in information technology". That language consequently must be treated as a 
claim limitation. 

In her final rejection. Examiner further argues that "users who are not specialists in 

information technology" is "non-functional descriptive data" because 

30 it does not preclude specialists in information technology from using the 

graphical user interface to perform operations on the model entity. Any 
type of user could be specified in the claimed system and the structural 
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elements and manipulative functionality would remain the same. (Final 
rejection, page 3) 

The point of the limitation "users who are not specialists in information technology" is 
5 not who it excludes but who it includes. The limitation points out a clear distinction 
between Buteau and Applicant's system: in Bateau, changes necessary to adapt the 
model for individual enterprises are made by architects and planners (col. 6, line 1 5), i.e. 
technical people; non-technical users can change the information in the model but not the 
model itself 

10 

As for the "patentable weight" of the limitation, it is repeatedly pointed out in the 

Specification that a large part of the value of the invention comes from the fact that it can 

be used by everyone who is collaborating in the business in which the invention is being 

used. See in this regard paragraphs 0130 through 0136. Moreover, even the most 

15 cursor)'- reflection on the history of digital data processing leaves no doubt thai the user 

interface is crucial to the usability of a technology. In the early 70's, for example, the 

WYSIWYG GUI for word processing replaced text processing languages like trolT and 

turned word processing into a task for clerical help. A 

system for supporting management of a collaborative activity by persons 
20 involved therein, the persons not being specialists in information 

technology 

represents the same kind of progress over systems like those of Buteau, which is not 
usable by "persons involved therein [who are not] specialists in information technology" 
25 to support management of a collaborative activity. That being the case, the limitation 
clearly has patentable weight. 



Additional limitatiom of the claims that are dependent from claim 211 that are not 

disclosed in Bateau 

30 Claims 1 92- 1 96 all involve the use of the graphical user interface to 

access the representations of the related further information via the model 
entities to which the representations are related 
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Buteau's way of accessing related further information is of course the SQL query 
interface of FIG, 9, and that interface is not usable by "persons . . . who are not specialists 
in information technology", as required by claim 211, and consequently, Buteau does not 
disclose the further 1 imitations of claims 192-196. 

The rejections of claims 195 and 196 under 35 U.S.C. 103 

As set forth in MPEP 2142, rejection of a claim under 35 U.S.C. 103 requires that 

Examiner establish a prima facie case of obviousness of the claimed invention. One 
element of this case is that the combination of references which forms the basis of the 
rejection must disclose all of the limitations of the claims under rejection. The rejections 
of claims 1 95 and 1 96 thus depend on the anticipation of claim 21 1 by Buteau and 
consequently cannot stand if, as demonstrated above, Buteau does not anticipate claim 
211. 

The rejection of claim 198 as anticipated by Buteau 

The method set forth in the claim is the method used in Applicant's system to create a 
mode! entity and relate the model entity to other model entities in a hierarchy and another 
hierarchy. Limitations of the claim that are not disclosed in Buteau include: 

• "a representation of a model entity [which is] capable of simultaneously belonging to 
a hierarchy and another hierarchy" {lines 5-7} 

• "the processor providjes] an interface for one or more users of the system who are not 
specialists in information technology" and the steps of the method are performed 
using that interface (lines 10-12). 

• the method steps of the body of the claim: 

- "receiving a definition of a model entity belonging to the model of the 
collaborative activity from a user via the interface (par. 0125) and 
responding thereto by producing a. representation of the model entity in the 
database" (lines 14-17) 

- "receiving a first indication of a first hierarchical relationship between the 
model entity and another model entity belonging to the hierarchy from the 
user via the interface and responding thereto by relating the model entity to 
the other mode! entity in the hierarchy" (lines 1 8-22) 
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- "receiving a second indication of a second hierarchical relationship 

between the model entity and a third model entity belonging to the other 
hierarchy from the user via the interface and responding thereto by relating 
the model entity to the third model entity in the other hierarchy" (lines 23- 
5 26) 

As set forth in more detail in the discussion of claim 21 1 above, Buteau does not disclose 
mode! entities that are capable of belonging to a hierarchy and another hierarchy, nor 
does Buteau disclose an interface for non-technical users that permits them to perforin the 
method steps of the claim. As to the patentable weight of this distinction, see the 

10 discussion of claim 211. As for the three method steps, the only interface in Buteau 
which is available to "users of the system who are not specialists in information 
technology" is that shown in FIG. 8. There is no disclosure of what can be done with the 
GUI of FIG, 8 other than that of the figure and of col. 22, 20-31. None of this disclosure 
indicates thai the GUI is used in Buteau to add entities to the model or change 

15 hierarchical relationships between model entities. Indeed, because adding a new model 
entity and changing the hierarchical relationships between model entities both involve 
changing the available attributes and this can only be done by the "enterprise architect", 
the disclosure strongly suggests that the GUI of FIG. 8 cannot be used to perform any of 
the steps of Applicant's method. Because tin s is the case, Buteau also does not anticipate 

20 claim 1 98 or any of the claims dependent therefrom. 

Additional limitations of the claims that are dependent, from claim 198 that are not 
disclosed in Buteau 

Claims 199-202 have to do with ways in which Applicant's GUI shows hierarchical 
25 relationships. Since Buteau's GUI of FIG. 8 does not show hierarchical relationships, 
Buteau does not show the additional limitations of the claims. The additional limitations 
of claims 203-209 are similar io the additional limitations of claims 192-196 and as 
explained with regard to those limitations, are not disclosed in Buteau. 

30 Conclusion 
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In the foregoing, Applicant has complied with the requirements of 37 C.F.R. 41.37 with 
regard to his brief and has demonstrated in the brief that Bateau does not disclose all of 
the limitations of claims 191-194 and 197-211 and consequently does not anticipate any 
of those claims and that because Buteau does not disclose all of the limitations of claim 
2.11, Examiner has failed to establish a prima facie case of obviousness with regard to 
claims 195 and 196. That being the case, the rejections cannot stand and Applicant 
respectfully requests that the Board of Appeals reverse Examiner with regard to all of her 
rejections and remand the application to Examiner for further processing as indicated by 
the reversals. 

Rl. s pect lulls si ib m j tted 
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(8) Appendix of claims 



1 ( hums I - 125: canceled 

2 Claims 126-186: canceled 

3 Claims 187-190: canceled 

1 191. The system set forth in claim 211 wherein: 

2 there is a plurality of types of model entities; and 

3 the graphical user interface shows a model entity's type, 

1 192, The system set forth in claim 2 ! 1 wherein: 

2 the model further includes representations of further information that are related 

3 to certain of the representations of the model entities; and 

4 the graphical user interface further permits the user to access the representations 

5 of the related further information via the model entities to which the representations are 

6 related. 

1 193. The system set forth in claim 192 wherein: 

2 the graphical user interface further permits the user to modify the further 

3 information. 



S 194, The system set forth in claim 193 wherein: 

2 the further information is a document that is accessible to the system. 

1 195. The system set forth in claim 193 wherein: 

2 the further information is a message sent to the person by another person. 

1 196. The system set forth in claim 194 wherein: 

2 the further information is a discussion concerning the model entity among the 



persons. 
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1 197, A data storage device, the data storage device being characterized in thai: 

2 the data storage device contains a program which, when executed in a computer 

3 system, implements the system set forth in claim 211. 

1 198, A method of supporting management of a collaborative activity in a system which 

2 includes a processor, the processor having access to a database containing a model of the 

3 collaborative activity, the model including representations of model entities, a given 

4 representation of a model entity 1 being capable of simultaneously belonging to 

5 hierarchies including a hierarchy and another hierarchy, and the representations of model 

6 entities providing access to information relating to the collaborative activity, the 

7 processor providing an interface for one or more users of the system who are not 

8 specialists in information technology, and the method comprising the steps performed in 

9 the system of: 

10 receiving a definition of a model entity belonging to the model of the 
1.1 collaborative activity- from a user via the interface and responding thereto by producing a 

12 represen tation of the model enti ty in the database; and 

13 receiving a first indication of a first hierarchical relationship between the model 
.14 entity and another model entity belonging to the hierarchy from the user via the interface 

15 and responding thereto by relating the mode! entity to the other model entity in the 

16 hierarchy and 

1? receiving a second indication of a second hierarchical relationship between the 

.18 model entity and a. third model entity belonging to the other hierarchy from the user via 

19 the interface and responding thereto by relating the model entity to the third mode! entity 

20 in the other hierarchy. 

1 199. The method set forth in claim 1 98 further comprising the step of: 

2 receiving an indication from the user via the interface that one or the other of the 

3 hierarchical relationships is to be shown in the interface and responding thereto by 

4 showing the indicated relationship in the interface. 

I 200, The method set forth in claim 198 wherein: 
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2 the hierarchy and the other hierarchy are different types of hierarchical 

3 relationships. 

1 201. The method set forth in claim 200 wherein the method further comprises the steps 

2 of: 

3 receiving a third indication from the user via the interface of the type of 

4 hierarchical relationship to he used in displaying the model entity in the interface; and 

5 responding thereto by displaying the model entity in the interface using the 

6 indicated hierarchical relationship. 

t 202. The method set forth in claim 199 wherein: 

2 the indicated hierarchical relationship is shown in the interface by displaying 

3 model entities as sorted by the relationship, 

t 203. The method set forth in claim 198 wherein the representation of the model entity 

2 includes a. representation of information about the collaborative activity and 

3 the method further comprises the steps of: 

4 receiving a third indication of the model entity from the person via the interface; 

5 receiving a fourth indication of the information from the user via the interface; 



6 and 

7 responding thereto by producing the representation of the information in the 

8 interface as part of the representation of the model entity in the interface. 



t 204. The method set forth in claim 203 further comprising the steps of: 

2 receiving a fifth indication from the user via the interface that the information in 

3 the representation of the information in the representation of the model entity is to be 

4 displayed; and 

5 responding thereto by showing the indicated information in the interface. 
1 205, The method set forth in claim 203 further comprising the step of: 
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2 receiving a sixth information from the user via the interface that the information 

3 in the representation of the information in the representation of the model entity is to he 

4 modified; and 

5 responding thereto by permitting the user to modify the information. 

! 206. The method set forth in claim 203 further comprising the steps of: 

2 receiving a. sixth indication from the user via the interface that the model entities 

3 are to he sorted by values of the information in the representation of the information in 

4 the representation of the model entity; and 

5 responding thereto by showing the sorted model entities in the interface. 

1 207. The method set forth in claim i 98 further comprising the steps of: 

2 receiving a third indication from the user via the interface of a model entity; 

3 receiving a fourth indication that further information is to be related to the 



4 indicated model entity; and 

5 responding thereto by relating a representation of the further information to the 

6 representation of the indicated model entity. 

1 208, The method set forth in claim 207 further comprising the steps of: 

2 receiving a fifth indication from the user via the interface that the further 

3 information related to the model entity is to be displayed; and 

4 responding thereto by showing the related further information in the interface. 

1 209. The method set forth in ciaim 208 further comprising the steps of: 

2 receiving a sixth indication from the user via the interface that the further 

3 information related to the model entity is to be modified; and 

4 responding thereto by modifying the related further information. 



210. A data storage device, the data storage device being characterized in that: 
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beavenO l.OOl 

2 the data storage device contains a program which, when executed in a computer 

3 system, implements the method set forth in claim 198. 

1 211, A system for supporting management of a collaborative activity by persons involved 

2 therein, the persons not being specialists in information technology and 

3 the system comprising: 

4 a representation of a model of the collaborative activity, the representation being 

5 accessible to a processor and the model of the collaborative activity including model entities, 

6 the model entities providing access to information concerning the collaborative activity, being 

7 organized into a plurality of hierarchies having a plurality of types, and a given model entity 

8 being capable of simultaneously belonging to a hierarchy having one of the types and a 

9 hierarchy having another of the types; and 

10 a graphical user interface for the system which the processor provides to the persons, 

1 1 the graphical user interface permitting a person of the persons to perform operations on a mode! 

12 entity as limited by a type of access which the person has to the model entity, the operations 

13 including controlling access to the model entity, creating, modifying, and/or deleting the model 

14 entity, assigning the model entity to a location in a hierarchy, accessing and/or modifying the 

15 information concerning the collaborative activity via the mode! entity, viewing model entities as 

16 ordered by a hierarchy to which the entities belong, and viewing model entities as ordered by a 
I? value in the information concerning the collaborative activity to which the entities give access. 
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(9) Evidence appendix 

(None) 

(JO) Related proceedings appendix 

(None) 



